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Prefix Exclude Option for DHCPv6é-based Prefix Delegation 
Abstract 


This specification defines an optional mechanism to allow exclusion 
of one specific prefix from a delegated prefix set when using 
DHCPv6-based prefix delegation. The new mechanism updates RFC 3633. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 
(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 
Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6603. 
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1. Introduction 


This specification defines an optional mechanism and the related 
DHCPv6 option to allow exclusion of one specific prefix from a 
delegated prefix set when using DHCPv6-based prefix delegation. 


The prefix exclusion mechanism is targeted at deployments where 
DHCPv6-based prefix delegation is used, but a single aggregated 
route/prefix has to represent one customer, instead of using one 
prefix for the link between the delegating router and the requesting 
router and another prefix for the customer network. The mechanism 
defined in this specification allows a delegating router to use a 
prefix out of the delegated prefix set on the link through which it 
exchanges DHCPv6 messages with the requesting router, and is intended 
for use in networks where each requesting router is on its own 
layer-2 domain. 


2. Requirements and Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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3. Problem Background 


DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit 
limitation described in Section 12.1 of [RFC3633] that a prefix 
delegated to a requesting router cannot be used by the delegating 
router. This restriction implies that the delegating router will 
have two (non-aggregatable) routes towards a customer: one for the 
link between the requesting router and the delegating router, and one 
for the customer site behind the requesting router. 


There are architectures and link models where a host (e.g., a mobile 
router, also acting as a requesting router) always has a single (/64) 
prefix configured on its uplink interface and the delegating router 
is also the requesting router’s first-hop router. Furthermore, it 
may be required that the prefix configured on the uplink interface 
has to be aggregatable with the delegated prefixes. This introduces 
a problem in how to use DHCPv6-PD together with stateless [RFC4862] 
or stateful [RFC3315] address autoconfiguration on a link where the 
/64 advertised is also part of the prefix delegated (e.g., /56) to 
the requesting router. 


4. Solution 
4.1. Prefix Delegation with Excluded Prefixes 


This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE 
(67), that is used to exclude exactly one prefix from a delegated 
prefix. The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX 
TAprefix-options field. There can be at most one OPTION_PD_EXCLUDE 
option in one OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option 
allows prefix delegation where a requesting router is delegated a 
prefix (e.g., /56) and the delegating router uses one prefix (e.g., 
/64) on the link through which it exchanges DHCPv6 messages with the 
requesting router with a prefix out of the same delegated prefix set. 


A requesting router includes an OPTION_ORO option with the 
OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, or Rebind 
message to inform the delegating router about the support for the 
prefix delegation functionality defined in this specification. A 
delegating router may include the OPTION_PD_EXCLUDE option code in an 
OPTION_ORO option in a Reconfigure message to indicate that the 
requesting router should request OPTION_PD_EXCLUDE from the 
delegating router. 
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The delegating router includes the prefix in the OPTION_PD_EXCLUDE 
option that is excluded from the delegated prefix set. The 
requesting router MUST NOT assign the excluded prefix to any of its 
downstream interfaces. 


4.2. Prefix Exclude Option 


0 1 2 3 
0: D2. 3 AS Or PB Or 1-203. 45. o 9 ON DL 23> AD 16°78 9 OL 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
OPTION_PD_EXCLUDE | option-len | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
prefix-len | IPv6 subnet ID (1 to 16 octets) 7 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+—+ 


Prefix Exclude Option 
Oo option-code: OPTION_PD_EXCLUDE (67). 


Oo option-len: 1 + length of IPv6é subnet ID in octets. A valid 
option-len is between 2 and 17. 


Oo prefix-len: The length of the excluded prefix in bits. The 
prefix-len MUST be between ’OPTION_IAPREFIX prefix-length’+1 and 
128. 


o IPv6 subnet ID: A variable-length IPv6 subnet ID up to 128 bits. 


The IPv6é subnet ID contains prefix-len minus ’OPTION_IAPREFIX prefix- 
length’ bits extracted from the excluded prefix starting from the bit 
position ’OPTION_IAPREFIX prefix-length’. The extracted subnet ID 
MUST be left-shifted to start from a full octet boundary, i.e., left- 
shift of ’OPTION_IAPREFIX prefix-length’ mod 8 bits. The subnet ID 
MUST be zero-padded to the next full octet boundary. 
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The encoding of the IPv6 subnet ID can be expressed in a C-like 
pseudocode as shown below: 


uint128_t pl; // the delegated IPv6 prefix 
uint128_t p2; // the excluded IPv6 prefix 

uint1l6_t a; // the OPTION_IAPREFIX prefix-length 
uint8_t b; // the excluded IPv6 prefix length 


uint8_t s; 


// sanity checks 


s = 128-a; // size of non-prefix bits 
assert (b>a); // b must be at least atl 
assert (pl>>s == p2>>s); // pl and p2 must share a common 


// prefix of ‘a’ bits 


// calculate the option content 


uintl6_t c = b-a-l; // the IPv6_subnet_ID_length-1 in bits 
uint1l6_t d = (c/8)+1; // the IPv6_subnet_ID_length in octets 
uint128_t p = p2<<a; // p is the IPv6 subnet ID that has the 


// common pl prefix left-shifted out to 
// a full octet boundary (trailing bits 
// are zeroed) 


// populate the option 
uint8_t* id = &OPTION_PD_EXCLUDE.IPv6_subnet_ID; 


OPTION_PD_EXCLUDE.option_len = d+1; 
OPTION_PD_EXCLUDE.prefix_len = b; 


while (d-- > 0) { 
xid++ = p>>120; 
p <<= 8; 


} 


The OPTION_PD_EXCLUDE option MUST only be included in the 
OPTION_IAPREFIX IAprefix-options [RFC3633] field. 


Any prefix excluded from the delegated prefix MUST be contained in 
OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX. 


The prefix included in the OPTION_PD_EXCLUDE option shares the same 
preferred-lifetime and valid-lifetime as the delegated prefix in the 
encapsulating OPTION_IAPREFIX option. 


The prefix in the OPTION_PD_EXCLUDE option MUST be part of the 
delegated prefix in the OPTION_IAPREFIX. For example, the requesting 
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router has earlier been assigned a 2001:db8:dead:beef::/64 prefix by 
the delegating router, and the delegated prefix in the 
OPTION_IAPREFIX is 2001:db8:dead:bee0::/59. In this case, 2001:db8: 
dead:beef::/64 is a valid prefix to be used in the OPTION_PD_EXCLUDE 
option. The OPTION_PD_EXCLUDE option would be encoded as follows: 


0 1 2 3 
O12:3.4 5 67.8 9 01.234 5 67-8 9:0 12:°3.4°5 67 8.9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| OPTION_PD_EXCLUDE | 2 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 64 Joļıļıļıļzļoļoļo] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 
+- 3 zero-padded bits follow 


+- using C syntax: Oxef << (59 % 8) 
Note: 59 mod 8 = 3 


5. Delegating Router Solicitation 


The requesting router locates and selects a delegating router in the 
same way as described in Section 11 [RFC3633]. This specification 
only describes the additional steps required by the use of the 
OPTION_PD_EXCLUDE option. 


5.1. Requesting Router 


If the requesting router implements the solution described in Section 
4.1, then the requesting router SHOULD include the OPTION_PD_EXCLUDE 
option code in the OPTION_ORO option in Solicit messages. 


Once receiving Advertise message(s), the requesting router uses the 
prefix(es) received in OPTION_PD_EXCLUDE, in addition to the 
advertised prefixes, to choose the delegating router. The requesting 
router MUST proceed to the Prefix Delegation procedure described in 
Section 6.1. If the Advertise message did not include the 
OPTION_PD_EXCLUDE option, then the requesting router MUST fall back 
to normal behavior, as described in Section 11.1 of [RFC3633]. 


5.2. Delegating Router 


If the OPTION_ORO option in the Solicit message includes the 
OPTION_PD_EXCLUDE option code, then the delegating router knows that 
the requesting router supports the solution defined in this 
specification. If the Solicit message also contains an IA_PD option, 
the delegating router can delegate to the requesting router a prefix 
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that includes the prefix already assigned to the requesting router’s 
uplink interface. The delegating router includes the prefix 
originally, or to be, assigned to the requesting router in the 
OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option 
in the Advertise message. 


If the OPTION_ORO option in the Solicit message does not include the 
OPTION_PD_EXCLUDE option code, then the delegating router MUST fall 
back to normal behavior, as described in Section 11.2 of [RFC3633]. 


If the OPTION_ORO option in the Solicit message includes the 
OPTION_PD_EXCLUDE option code but the delegating router does not 
support the solution described in this specification, then the 
delegating router acts as specified in [RFC3633]. 


6. Requesting Router-Initiated Prefix Delegation 


The procedures described in the following sections are aligned with 
Section 12 of [RFC3633]. In this specification, we only describe the 
additional steps required by the use of the OPTION_PD_EXCLUDE option. 


6.1. Requesting Router 


The requesting router behavior regarding the use of the 
OPTION_PD_EXCLUDE option is mostly identical to the steps described 
in Section 5.1, with the difference being the use of a DHCPv6 Request 
instead of an Solicit message. The requesting router SHOULD include 
the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6 
messages as described in Section 22.7 of [RFC3315]. The requesting 
router SHOULD include the OPTION_PD_EXCLUDE option code in the 
OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of 
[RFC3315]. 


The requesting router uses a Release message to return the delegated 
prefix(es) to a delegating router. The prefix(es) to be released 
MUST be included in the IA_PDs along with the excluded prefix 
included in the OPTION_PD_EXCLUDE option. The requesting router MUST 
NOT use the OPTION_PD_EXCLUDE option to introduce an additional 
excluded prefix in the Release message for which it originally got a 
valid binding. 


The requesting router must create sink routes for the delegated 
prefixes, minus the excluded prefixes. This may be done by creating 
sink routes for delegated prefixes and more specific routes for the 
excluded prefixes. 
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6.2. Delegating Router 


The delegating router behavior regarding the use of the 
OPTION_PD_EXCLUDE option is more or less identical to the step 
described in Section 5.2. The only difference is the DHCPv6 messages 
used to carry the OPTION_PD_EXCLUDE option. 


The delegating router may mark any prefix(es) in the IA_PD Prefix 
options in a Release message from a requesting router as ‘available’, 
excluding the prefix included in the OPTION_PD_EXCLUDE options. If 
the Release message contains a /’new’ excluded prefix in any 
OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply 
message with the Status Code set to NoBinding for that IA_PD option. 


7. Security Considerations 


Security considerations for DHCPv6 are described in Section 23 of 
[RFC3315]. For DHCPv6 Prefix Delegation, they are described in 
Section 15 of [RFC3633]. In particular, RFC 3633 provides 
recommendations for protection against prefix delegation attacks. 
This specification does not add any new security considerations 
beyond those provided by RFC 3633. 


8. IANA Considerations 
A new DHCPv6 Option Code has been reserved from the "Dynamic Host 
Configuration Protocol for IPv6é (DHCPv6)" registry for DHCP Option 
Codes. 

OPTION_PD_EXCLUDE (67) 
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